The present invention is related to communication in a telecommunication system, and more particularly to improving end-to-end communication in a modern telecommunication system.
Universal Mobile Telecommunication Systems (UMTS) provide a third generation (3G), broadband, packet-based network architecture. UMTS is endorsed by major standards bodies and manufacturers as the planned standard for mobile users around the world. The UMTS network transports text, digitized voice, digitized video, and multimedia at data rates up to and possibly higher than 2 Mbps. Once fully implemented, computer and phone users will be able to travel staying connected to the Internet with a consistent set of capabilities. Access is obtained through a combination of terrestrial wireless and satellite transmissions.
FIG. 1 illustrates a portion of a UMTS network. The network includes a core network part (CN) 1, which may be a network handling voice calls using UMTS Mobile-Services Switching Centers (UMSCs) 2 or may be a data network such as a General Packet Radio Service (GPRS) network including Serving GPRS Support Nodes (SGSNs) 2. The CN 1 may also include one or more Media Gateways (MGW) (not shown) to control data flow within the CN 1 and between the CN 1 and other networks. A subscriber or User Equipment (UE) 3 is coupled to the CN 1 via an access network 4 referred to as a Universal Terrestrial Radio Access Network (UTRAN). More particularly, the UMSCs/SGSNs 2 are connected to Radio Network Controllers (RNCs) 5,6 of the UTRAN 4 over an interface referred to as the lu interface.
Each RNC 5, 6 forms part of a Radio Network Subsystem (RNSs) 7,8 which also comprises a set of Base Transceiver Stations (BTS) 9 referred to in UMTS terminology as Node B's. The interface between a RNC 5,6 and a Node B 9 is known as the lub interface. A Node B 9 provides the connection point for a UE 3 to the UTRAN 4, with the interface between the Node B 9 and the UE 3 known as the Uu interface. The interface between two RNCs 5,6 is known as the lur interface. The RNS (RNS 7 in FIG. 1) which connects a UE 3 to the CN 1 at any given time is referred to as the Serving RNS (SRNS) for that particular UE 3. Two UEs 3, 10 may also communicate with each other via respective RNCs through the CN 1 involving one or more MGWs. The interface used to convey data between consecutive MGWs in the CN 1 is the Nb interface.
FIG. 2 illustrates in general terms the bearer structure used by a UTRAN to carry user data between the UE 3 and the CN 1. When it is required to establish a user plane (UP) connection, the responsible UMSC or SGSN 2 instructs the UTRAN 4 to establish a logical connection between the UMSC or SGSN 2 and the UE 3. This logical connection is referred to as a Radio Access Bearer (RAB). The established RAB inherits the requirements of the requested UMTS service, e.g., Quality of Service, etc. Based on the inherited requirements of the RAB, the RNC 5,6 establishes UP connections with the CN 1 (i.e., UMSC or SGSN 2) and with the UE 3. The connection between the RNC 5,6 and the CN 1 is referred to as the lu bearer, while the connection between the RNC 5,6 and the UE 3 is referred to as the Radio Bearer (RB). Both of these bearers represent further logical channels, with the RNC performing a mapping between them. The bearers themselves are mapped onto appropriate traffic channels for transmission over the respective interfaces (Nb, lu, lub, and Uu). A Radio Resource Control (RRC) protocol specifies the UE3 to UTRAN 4 radio interface.
In addition to carrying user data, the lu bearer carries related control information between the UTRAN 4 and the CN 1. Work is currently ongoing under the auspices of the 3GPP to specify the lu UP protocol for carrying this control information.
As of the filing date of the above-identified priority application, the current 3GPP specification was R99. Accordingly, in this document, reference is made to the then published lu UP specification TS 25.415 version 3.5.0 and RRC specification TS 25.331, version 3.5.0 (the first Nb UP specification was published after the priority date). Currently, the lu UP specification is TS 25.415 (v4.2, 2001-9), the Nb UP specification is TS 29.415 (v4.1, 2001-9), and the RRC specification is TS 25.331 (v4.1, 2001-3).
Referring to FIG. 3, a functional model of the lu UP protocol layer in Support Mode is illustrated. The lu UP protocol layer in Support Mode includes three sets of functions: frame handler functions; procedure control functions; and non access stratum (NAS) data streams specific functions. The frame handler function is responsible for framing and de-framing the different parts of an lu UP protocol frame. This function takes the different parts of the lu UP protocol frame and sets the control part field to the correct values, including the handling of the frame number. It also ensures that the frame control part is semantically correct. This function is responsible for interacting with the Transport layers. This function is also responsible for the CRC (cyclic redundancy checking) check of the lu UP frame header. The lu UP frame with header CRC check error is discarded.
The NAS Data Streams specific function(s) are responsible for a “limited manipulation” of the payload and the consistency check of the frame number. If a frame loss is detected due to a gap in the sequence of the received frame numbers, it is reported to the procedure control function. These functions are responsible for the CRC check and frame quality classification handling as described below. The functions interact with the upper layers by exchanging lu data stream blocks of lu UP frame payload and provide service access to the upper layers for the procedure control functions.
On the lu UP in Support Mode the frames are classified with the Frame Quality Classifier (FQC). This classifying is based on the radio frame classification and the setting of the RAB attribute ‘Delivery of erroneous SDUs’. The RAB attribute ‘Delivery of erroneous SDUs’ indicates whether erroneous frames should be delivered or not. If it is set to YES then the UP entity implements, error checking and sets FQC bits (FQC field) accordingly; bad frames are delivered to the UP layer. If it is set to NO then the UP entity performs error checking and if a bad frame is detected then it is discarded. These settings are required only when the payload is to be examined by upper layer services. If it is set to NA then no checking is performed. See 3GPP TS 29.232, version 0.3.0 (current version 4.0.0), Media Gateway Controller—Media Gateway Interface.
FIG. 4 illustrates the main input and output information for the frame quality classification function on the lu UP. The FQC information in the uplink path is handled by a serving RNC (SRNC) in the UTRAN 400. In the SRNC on the sending side, the Support Mode functions 420 receive the radio frame quality information as input together with the frame. Based on this information, the FQC is set for the frame, a CRC is or is not added (depending on the protocol data unit type) and the frame is sent to the CN.
Tables 1–3 below outline how the FQC is defined by R99. Table 1 below outlines the SRNC behavior on the uplink path for each associated FQC field setting and ‘Delivery of erroneous SDUs (service data units)’ RAB attribute:
Table 1: FQC Handling in the RNC on Uplink (lu interface)
INPUTACTION(for each subflow)(on lu UP frame)Delivery of erroneousRadio FrameAction taken in SRNC on theSDUsClassificationsending sideYesBadSet FQC to ‘bad radio’NoBadFrame not sentno-error-detection-Any valueSet FQC to ‘good’considerationAny valueGoodSet FQC to ‘good’
Referring to Table 1, if there is at least one subflow with the ‘Delivery of erroneous SDUs’ set to “No” and for at least one of those subflows the radio frame classification is “Bad” then the lu UP frame is not sent. If there is at least one subflow with the ‘Delivery of erroneous SDUs’ set to “Yes” and for at least one of those subflows the radio frame classification is “Bad” then the lu UP frame is sent with FQC set to “Frame bad due to radio.” Otherwise the lu UP frame is sent with FQC set to “frame good”. This is because only one FQC is sent for all RBs mapping into one lu, Nb bearer.
The Support Mode Functions 430 in the CN 410 on the receiving side performs a CRC check of the frame payload, if the CRC is present, and passes the appropriate frame and the appropriate frame quality classification information through the radio network layer service access point (RNL-SAP). Tables 2a and 2b below outline the CN behavior on the downlink and uplink path, respectively, for each associated CRC check result and ‘Delivery of erroneous SDUs’ RAB attribute scenario for the received frames:
TABLE 2aFQC Handling in the CN/RNC on Downlink (lu)INPUT(for each subflow)ACTIONDelivery of erroneous(on lu UP frame)SDUsPayload CRC check resultActions taken at CN on the receiving(for each subflow)(on lu UP frame)sideYes (at least one of theNot OKFrame forwarded with FQC set to ‘bad’subflows have this valuebut none have ‘No’)No (at least one of theNot OKDrop frame, send lu-UP-Statussubflows have this value)primitive indicating ‘no data’ at theRNL-SAP, if CNno-error-detection-Any resultFrame forwarded with FQC as setconsideration (all subflowshave this value)
TABLE 2bFQC Handling in the CN on received Uplink (lu)INPUT(for each subflow)ACTIONDelivery of erroneous(on lu UP frame)SDUsPayload CRC check resultActions taken at CN on the(for each subflow)(on lu UP frame)receiving sideYes (at least one of theNot OKFrame forwarded with FQC set tosubflows have this value‘bad’but none have ‘No’)No (at least one of theNot OKDrop frame, send lu-UP-Statussubflows have this value)primitive indicating ‘no data’ at theRNL-SAPno-error-detection-Any resultFrame forwarded with FQC as set byconsideration (allUTRANsubflows have this value)Any valueOKFrame forwarded with FQC as set byUTRAN
Referring to Tables 2a and 2b, if a CRC is available and the CRC check indicates that the lu UP is “Bad” and at least one subflow has the ‘Delivery of erroneous SDUs’ set to “No”, then the lu UP frame is dropped. If a CRC is available and the CRC check indicates that the lu UP frame is “Bad” and at least one subflow has the ‘Delivery of erroneous SDUs’ set to “Yes”, then the lu UP frames are forwarded with the FQC set to “Bad.” Otherwise, the lu UP frame is forwarded with the FQC as received.
The Support Mode Functions 430 in the CN 410 on the sending side adds a CRC, if necessary to the frame payload and passes it together with the FQC. If the payload stems from a transcoding unit of the NAS within the CN 410 the FQC is always set to good.
The Support Mode Functions 420 in the SRNC of the UTRAN 400 then perform a CRC-check, if the CRC is present. Based on the CRC check, a decision is made whether to deliver the frame or not, as outlined in Table 3 below:
TABLE 3Conventional FQC Handling in the RNC on DownlinkINPUTACTION‘Delivery ofCRC check(on lu UP frame)erroneous SDUs’(if payload CRC present)Actions taken at SRNC on the(for each subflow)FQC(on lu UP frame)receiving sideYes‘good’Not OKDrop frameNo‘good’Not OKDrop frameno-error-detection-‘good’Any resultPass the frame to radio interfaceconsiderationprotocolsAny value‘good’OKPass the frame to radio interfaceprotocolsAny value‘bad’ orAny resultDrop frame‘bad radio’
Referring to Table 3, if a CRC is available and the CRC check indicates that the lu UP is “Bad” then the frame is dropped, regardless of the ‘Delivery of erroneous SDUs’ RAB attribute indication. Otherwise, the frames are passed to radio interface protocols. The FQC field is not forwarded to the UE. When the received FQC is set to ‘bad’ or ‘bad radio’, the frame is dropped.
Cellular networks depend heavily on codecs to compress speech in order to efficiently utilize the expensive bandwidth resources both in the radio interface and in the transmission networks. Unnecessary transcoding of speech significantly degrades quality and, therefore, cellular systems try to avoid it for mobile-to-mobile calls when both UEs and the network support a common codec type. A transcoder functions to change the encoding of information from one particular encoding scheme to another, most commonly to/from a compressed speech algorithm from/to pulse code modulation (PCM).
The 3GPP standardization includes Transcoder Free Operation (TrFO), which allows the configuration of speech or multimedia calls without a transcoder device being physically present in the communication path and hence no control, conversion, or other functions are associated with the call. For TrFO calls, the compressed speech is carried end to end (RNC to RNC or between RNC and another compressed voice terminal).
The Nb UP operates in the UP of the CN and is used to convey data between MGWs. The Nb UP protocol is initiated at one MGW and acknowledged by an adjoining MGW. The Nb framing protocol is inherited from the lu framing protocol. The Support Mode is used for compressed voice.
In TrFO, a transcoder is no longer located where the lu interface terminates. However, without a transcoder the FQC function will not work correctly. Faults can occur inside the CN and the quality of TrFO calls will drop drastically when the quality of the transmission over the air interface decreases. Currently, FQCs are neither transported within the CN nor to the UE via the downlink path. A mechanism is needed to provide for the handling of CRC and FQC information on the network level for all applications, data or multimedia, that rely on these functions, thereby improving quality end-to-end.